nathelper: port add_contact_alias() and handle_ruri_alias() #3769
+559
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Any updates here? No progress has been made in the last 30 days, marking as stale. |
Those are slightly better version of the fix_nated_contact()
originating from Kamailio.
The problem with fix_nated_contact() is that it could cause
RURI for in-dialog requests contain a different IP address as
compared to the Contact in the initial INVITE.
Most endpoints are fine with that, however tere are some,
notably MS Teams, which would reject such request with:
SIP/2.0 500 Internal Server Error
Reason: Q.850;cause=47;text="76a7afc3-d033-4988-9000-f70b41e4db1b;RURI in request has invalid FQDN value"
The full exchange when using fix_nated_contact() is as follows:
UA->OpenSIPS (initial INVITE):
opensips[42757]: RECEIVED message from 10.2.80.32:5060:
INVITE sip:[...]
Contact: <sip:[...]@10.2.80.22:5060>
^^^^^^^^^^
OpenSIPS->UA:
SIP/2.0 100 Giving it a try
SIP/2.0 200 OK
UA->OpenSIPS:
ACK sip:[...]
OpenSIPS->UA (re-INVITE):
opensips[42759]: SENDING message to 10.2.80.32:5060:
INVITE sip:[...]@10.2.80.32:5060 SIP/2.0
^^^^^^^^^^
UA->OpenSIPS:
SIP/2.0 500 Internal Server Error
sobomax
force-pushed
the
pr_contact_alias
branch
from
931b356 to
13b7504
Compare
Member
|
Hi @sobomax , thanks for the contribution here. Here are some first thoughts:
The benefit of these new functions is (as far as I can understand) to simplify a bit the scripting IF you do NOT WANT to use dialog support. Otherwise, it may complicate even more the scripting, as the user has to use more functions. Maybe we can add a new flag to fix_nated_contact(), in order to add this new param ? And we can use the "maddr" param (standard) which is automatically recognized by OpenSIPS (in routing RURI) for overriding the actual RURI domain/port |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Port
add_contact_alias()andhandle_ruri_alias()functionsDetails
Those are slightly better version of the
fix_nated_contact()originating from Kamailio.The problem with
fix_nated_contact()is that it could cause RURI for in-dialog requests contain a different IP address as compared to the Contact in the initial INVITE.Most endpoints are fine with that, however tere are some, notably MS Teams, which would reject such request with:
The full exchange when using
fix_nated_contact()is as follows:UA->OpenSIPS (initial INVITE):
OpenSIPS->UA:
UA->OpenSIPS:
OpenSIPS->UA (re-INVITE):
UA->OpenSIPS:
Solution
Use
add_contact_alias()in the INVITE/200 OK paths andhandle_ruri_alias()in in-dialog request path.UA->OpenSIPS (initial INVITE):
OpenSIPS->UA:
OpenSIPS->B2BUA (initial INVITE):
B2BUA->OpenSIPS (re-INVITE):
OpenSIPS->UA (re-INVITE):
Compatibility
Should not be any if used correctly. Special test case for the voiptests has been created and will be enabled once the change is merged into the opensips/master.